In many computer systems, a booting of the system occurs through a series of steps in which initialization is performed, self-testing occurs, a basic input/output system (BIOS) is loaded and executed, and finally control may be passed off to an operating system (OS).
In many systems, trusted code, such as code present in a non-volatile storage of the system provided by an original equipment manufacturer (OEM), operates in the same privilege level as third party code. Accordingly, there is a risk that untrusted or errant third party code can corrupt the system, particularly in a pre-boot environment. As one example, so-called Unified Extensible Firmware Interface (UEFI) code in accordance with the UEFI Specification Version 2.0 (dated Feb. 21, 2006) calls for the separation of pre-boot and boot environments into a variety of phases. However, in these phases both OEM trusted code and third party untrusted/errant code can execute in the same privilege level.
Firmware-based security features, such as cryptographic loading and checking of UEFI-based platform code application signatures using digital signature technology like Authenticode, can only be guaranteed to operate as designed in the field if the implementation of the codes is isolated from untrusted content. To date, pre-OS isolation has been effected via ad hoc, incomplete mechanisms like system management mode (SMM), but in a world where SMM may not be available, or to meet the cross-architecture requirements of UEFI, other solutions are needed.